Skip to content

Internal docs for Rust/callback interface calls #2550

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

bendk
Copy link
Contributor

@bendk bendk commented May 29, 2025

No description provided.

@bendk bendk requested a review from a team as a code owner May 29, 2025 18:35
@bendk bendk requested review from badboy and removed request for a team May 29, 2025 18:35
Copy link
Member

@mhammond mhammond left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this! As usual, take these comments for what they cost!

@bendk bendk force-pushed the push-klvptxqyrnkw branch 2 times, most recently from cb388d1 to c91866f Compare May 30, 2025 13:53
Calling into foreign code has 2 major differences from [calling Rust code](./rust_calls.md):

* Foreign code is only called via an interface.
* The Rust code does not have access to a library with functions it can call.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to reword this slightly. Like what does it mean? Does it mean that "Rust doesn't know the functions it can call on the foreign language side".

It clashes a bit with the next paragraph, which says that the foreign code registers functions Rust can call?

I think I know what you mean, but I had to read it a few times to get it.


VTable methods work similar to a [Rust method call](./rust_calls.md)], with some exceptions.

Instead of returning the value as normal, it's written to an out pointer.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Super nit, but is it that returning means the foreign side writes the return value in a block of memory (heap or stack) and returns a pointer which points to the place in memory the Rust function can read the value from? Which then, it needs to "lift" and make it a Rust type?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not exactly, Rust passes in the pointer rather than having the foreign side return it. That makes the memory management a bit simpler. I updated the wording, tell me if it's clearer now.

VTable methods work similar to a [Rust method call](./rust_calls.md)], with some exceptions.

Instead of returning the value as normal, it's written to an out pointer.
This is because some foreign languages, like Python, have issues returning C structs like `RustBuffer`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does this mean, having issues returning C structs?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It means ctypes throws an exception rather than returns the value. The design choice completely baffles me. I updated the text and linked to the issue for that.

@bendk bendk force-pushed the push-klvptxqyrnkw branch from c91866f to 7e19d8f Compare June 2, 2025 21:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants